home *** CD-ROM | disk | FTP | other *** search
/ InfoMagic Internet Tools 1993 July / Internet Tools.iso / iso9660 / mail / pine / c_client.arc / text0050.txt < prev    next >
Encoding:
Text File  |  1993-07-31  |  1.7 KB  |  45 lines
  1. Yes, creating a new call in the API that fetches the extended header along
  2. with the 1st body part seems fine. 
  3.  
  4. I was going to mention this last time, but I was also thinking about the
  5. case when you're fetching envelopes.  If we do threading based on the
  6. References: field (I'm still investigating whether or not that is the way
  7. to go) then you'll want to fetch this extended header information with all
  8. the envelopes.  Since you can fetch them all with one RTT it's still only
  9. doubling, so I guess it's OK. 
  10.  
  11. I am a little worried about performance for threading. To do threading one
  12. has to fetch the envelopes of all the messages in the mailbox, as well as
  13. the References fields. 
  14.  
  15. While you're redesigning API's maybe an extended mail_fetchstructure could
  16. get the Resent-xxx, References and Newsgroups fields. Those are the ones
  17. for which we've got a clear need that I can think of.
  18.  
  19. LL
  20.  
  21.  
  22. On Fri, 23 Apr 1993, Mark Crispin wrote:
  23. > 
  24. > On Tue, 20 Apr 1993 23:52:45 -0400 (EDT), Laurence Lundblade wrote:
  25. > > I'm a little concerned about RTT's in a mailer that regularly fetches the
  26. > > Resent-XXX:, References:  and other fields (presumably many if not most
  27. > > good IMAP clients will do this). You're probably one to think about this
  28. > > more than I, but wouldn't it at least double the number of RTT's for a lot
  29. > > of the normal operations? Is doubling the RTT's a problem? I know there's
  30. > > probably not much else that can be done without breaking existing IMAP
  31. > > clients.
  32. > 
  33. > That's a good point.  I think that when the API is done for this there should
  34. > be some sort of means to all for it to be fetched it along with something else
  35. > to avoid the extra RTT.  How about fetching it along with section 1 of the
  36. > body?
  37. > 
  38. > It'd be a new API function, no matter what.
  39. > 
  40.  
  41.  
  42.  
  43.  
  44.  
  45.